To be honest, I don't like polluting standard-conformant c++ code with posix. I also understand that in our project we will definitely need fsync() for files and / or directories. What I suggest is to create a separate header, say util/native_file_operations_helpers.hpp with c++-conformant interface (no posix includes). At the same time put the implementation with all the posix-spacific calls to the util/native_file_operations_helpers_posix.cpp. Who knows, may be one day we will have util/native_file_operations_helpers_windows.cpp.
In this case we will include either util/native_file_operations_helpers_posix.cpp or util/native_file_operations_helpers_windows.cpp to the project conditionally using CMake means.

agree

You should probably add "trying to execute binlog_purge with currently active file specified in the command line". If I haven't missed this among other cases.

Please see case 9 below

I knew I missed it :)

I don't like the idea of exposing do_fsync() to public interface. I'd rather have
2 private methods

virtual void do_remove_object(std::string_view name) = 0;
virtual void do_fsync() = 0;

and 2 public methods:

void remove_object(std::string_view name) {
   do_remove_object(name);
   do_fsync();
}

void remove_objects(std::collection<std::string_view> names) {
    for(const auto &name: names) {
     do_remove_object();
   }
   do_fsync();
}

What do you think?

I think the way I proposed is more flexible. But if we agree that do_fsync is must have after remove_object or remove_objects, we can go your way. To be honest I think both approaches are more or less equal.
If you insist, I will change.

I would insist, flushing is not something users of the class should care about. For them, it should just work.

I have one concern here. The suggested scehema with single rename is totally OK for POSIX, renaming a file to an existing one is a well-defined atomic operation. No questions here.

However, as you may have already noticed our S3 uploads are not optimal. We always completely owerwrite full existing object. However, there is an area for improvemnt here. We can initiate a multipart upload and compose a new object from a reference to an existing one and a new data block.
In other words, if we have

/path/object1.data (1024 bytes)

we can create

/path/object2.data (2048 bytes total : 1024 from /path/object1.data and 1024 bytes from new data block upload)

However, S3 does NOT have a rename operation at all. So, you won't be able to just change the name of
/path/object2.data back to /path/object1.data.
You can only

1. delete /path/object1.data`
2. copy /path/object2.datato/path/object1.data
3. delete /path/object2.data`

So, my question here is what atomic rename scheme we should use so that we would have a single recovery algorithm for both file and s3 storage backends.

Still not 100% sure here but one of the options could be (for file storage backend)

1. create .tmp1 with new content
2. move original to .tmp2
3. rename .tmp1 to original
4. remove .tmp2

As per documentation S3 PutObject is atomic. So our implementation of s3_storage_backend::do_put_object is atomic. No changes needed here.
In other words: create - rename pattern is only for posix. For S3, PutObject is already atomic.

Yes, Kamil. Currently, PutObject is atomic and no problems with it. Here I am going a bit ahead of time when we decide to simulate this append operation with MultipartUploads. But again, this is definitely another task.